## -*- mode: html; coding: utf-8; -*-
## This file is part of CDS Invenio.
## Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 CERN.
##
## CDS Invenio is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
## published by the Free Software Foundation; either version 2 of the
## License, or (at your option) any later version.
##
## CDS Invenio is distributed in the hope that it will be useful, but
## WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
## General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with CDS Invenio; if not, write to the Free Software Foundation, Inc.,
## 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

<!-- WebDoc-Page-Title: WebAccess Admin Guide -->
<!-- WebDoc-Page-Navbar-Select: webaccess-admin-guide -->
<!-- WebDoc-Page-Revision: $Id$ -->

<h2>Contents</h2>

<strong>1. <a href="#1">Introduction, using roles</a></strong><br />
<strong>2. <a href="#2">WebAccess admin interface</a></strong><br />
<strong>3. <a href="#3">Example pages, illustrating snapshots</a></strong><br />
<strong>4. <a href="#4">Managing accounts / Access policy</a></strong><br />
<strong>5. <a href="#5">Managing login methods</a></strong><br />
<strong>6. <a href="#6">Firewall-like role definitions</a></strong><br />

<h2><a name="1">1. INTRODUCTION, USING ROLES</a></h2>
<pre>
  WebAccess is a common RBAC, role based access control, for all of
  CDS Invenio. This means that users are connected to roles that cover
  different areas of access. I.e <em>administrator of the photo
  collection</em> or <em>system librarian</em>. Users can be active in
  different areas and of course connected to as many roles as needed.

  The roles are connected to actions. An action identifies a task you
  can perform in CDS Invenio. It can be defined to take any number of
  arguments in order to more clearly describe what you are allowing
  connected users to do.

  For example the system librarian can be allowed to run bibindex on
  the different indexes. To allow system librarians to run the
  bibindex indexing on the field author we connect role <em>system
  librarian</em> with action <em>runbibindex</em> using the argument
  <em>index='author'</em>.

  Additionally, roles could have <em><a href="#6">firewall-like role
  definitions</a></em>. A definition is a formal description of which
  users are entitled to belong to the role. So you have two ways for
  connecting users to roles. Either linking explicitly a user with the
  role or describing the characteristics that makes users belong to
  the role.

  WebAccess is based on allowing users to perform actions. This means
  that only allowed actions are stored in the access control engine's
  database.
</pre>

<h2><a name="2">2. WEBACCESS ADMIN INTERFACE</a></h2>
<pre>
All the WebAccess Administration web pages have certain
features/design choices in common

- Divided into steps

  The process of adding new authorizations/information is
  stepwise. The subtitle contains information about wich step you are
  on and what you are supposed to do.

- Restart from any wanted step

  You can always start from an earlier step by simply clicking the
  wanted button. This is not a way to undo changes! No information
  about previous database is kept, so all changes are definite.

- Change or new entry must confirmed

  On all the pages you will be asked to confirm the change, with
  information about what kind of change you are about to perform.

- Links to other relevant admin areas on the right side

  To make it easier to perform your administration tasks, we have
  added a menu area on the right hand side of these pages. The menu
  contain links to other relevant admin pages and change according to
  the page you are on and the information you have selected.
</pre>

<h2><a name="3">3. EXAMPLE PAGES</a></h2>
<pre>
I. Role area
II. Example - connecting role and user


I. Role area</a>

  Administration tasks starts in one of the administration areas. The
  role area is the main area from where you can perform all your
  managing tasks. The other admin areas are just other ways of
  entering.

</pre>

<div class="snapshot">
<table class="navtrailbox">
    <tr>
        <td class="navtrailboxbody">
            <a href="" class="navtrail">Home</a> &gt; <a class=navtrail href="">Admin Area</a> &gt; <a class=navtrail href="">WebAccess Admin</a> &gt; <a class=navtrail href="">Manage WebAccess</a>  &gt; Role Administration
        </td>
    </tr>
</table>
<!-- end replaced page header -->

<div class="pagebody">
    <div class="pagebodystripeleft">
        <div class="pageboxlefttop">
        </div>
        <div class="pageboxlefttopadd"></div>
        <div class="pageboxleftbottomadd"></div>
        <div class="pageboxleftbottom">
        </div>
    </div>
    <div class="pagebodystriperight">
        <div class="pageboxrighttop">
        </div>
        <div class="pageboxrighttopadd"></div>
        <div class="pageboxrightbottomadd"></div>
        <div class="pageboxrightbottom">
        </div>
    </div>
    <div class="pagebodystripemiddle">

        <h1 class="headline">Role Administration</h1>

        <table class="admin_wvar" width="95%">

            <thead>
                <tr>
                    <th class="adminheaderleft" colspan="2">administration with roles as access point</th>
                </tr>
            </thead>
            <tbody>
                <tr>

                    <td style="vertical-align: top; margin-top: 5px; width: 75%;">

                        <dl>
                            <dt>Users:</dt>
                            <dd>add or remove users from the access to a role and its priviliges.</dd>
                            <dt>Authorizations/Actions:</dt>
                            <dd>these terms means almost the same, but an authorization is a <br />
                                    connection between a role and an action (possibly) containing arguments.</dd>
                                <dt>Roles:</dt>
                                <dd>see all the information attached to a role and decide if you want to<br />delete it.</dd>
                                </dl>
                                <table class="admin_wvar_nomargin">
                                    <tr>
                                        <th class="adminheader">id</th>
                                        <th class="adminheader">name</th>
                                        <th class="adminheader">description</th>
                                        <th class="adminheader">definition</th>
                                        <th class="adminheader">users</th>
                                        <th class="adminheader">authorizations / actions</th>
                                        <th class="adminheader">role</th>
                                        <th class="adminheader"></th>
                                        <th class="adminheader"></th>

                                    </tr>
                                    <tr><td class="admintdleft">2</td>
                                        <td class="admintdleft">photoadmin</td>
                                        <td class="admintdleft">Photo collection administrator</td>
                                        <td class="admintdleft">None</td>
                                        <td class="admintdleft"><a href="">add</a> / <a href="">delete</a></td>
                                        <td class="admintdleft"><a href="">add</a> / <a href="">modify</a> / <a href="">remove</a></td>
                                        <td class="admintdleft"><a href="">modify</a> / <a href="">delete</a></td>
                                        <td class="admintdleft"><a href="">show details</a></td>
                                        <td rowspan="3" style="vertical-align: top">

                                        </td>
                                    </tr>
                                    <tr>
                                        <td class="admintdleft">1</td>
                                        <td class="admintdleft">superadmin</td>
                                        <td class="admintdleft">superuser with all rights</td>
                                        <td class="admintdleft">allow email /.*@cern.ch/</td>
                                        <td class="admintdleft"><a href="">add</a> / <a href="">delete</a></td>
                                        <td class="admintdleft"><a href="">add</a> / <a href="">modify</a> / <a href="">remove</a></td>
                                        <td class="admintdleft"><a href="">modify</a> / <a href="">delete</a></td>
                                        <td class="admintdleft"><a href="">show details</a></td>
                                    </tr>
                                    <tr>
                                        <td class="admintdleft">3</td>
                                        <td class="admintdleft">webaccessadmin</td>
                                        <td class="admintdleft">WebAccess administrator</td>
                                        <td class="admintdleft">allow apache_user 'jekyll'
                                            de...</td>
                                        <td class="admintdleft"><a href="">add</a> / <a href="">delete</a></td>
                                        <td class="admintdleft"><a href="">add</a> / <a href="">modify</a> / <a href="">remove</a></td>
                                        <td class="admintdleft"><a href="">modify</a> / <a href="">delete</a></td>
                                        <td class="admintdleft"><a href="">show details</a></td>
                                    </tr>
                                </table>

                            </td>

                            <td style="vertical-align: top; margin-top: 5px; width: 25%;">

                                <dl>
                                    <dt><a href="">Create new role</a></dt>
                                    <dd>go here to add a new role.</dd>
                                    <dt><a href="">Create new action</a></dt>
                                    <dd>go here to add a new action.</dd>
                                </dl>

                            </td>
                        </tr>

                    </tbody>
                </table>

            </tbody>
        </table>
    </div>
</div>
</div>

<pre>

II. Example - connecting role and user</a>

  One of the important tasks that can be handled via the WebAccess Admin Web Interface
  is the delegation of access rights to users. This is done by connecting them to the
  different roles offered.

  The task is divided into 5 simple and comprehensive steps. Below follows the pages from
  the different steps with comments on the ongoing procedure.

- step 1 - select a role

  You must first select the role you want to connect users to. All the available roles are
  listed alfabetically in a select box. Just find the wanted role and select it. Then click on
  the button saying &quot;select role&quot;.

  If you start from the Role Area, this step is already done, and you start directly on step 2.

</pre>

<div class="snapshot">

   <table border="0" cellspacing="0" cellpadding="0" class="navtrailbox" width="100%" summary="">
    <tr>
     <td class="navtrailboxbody">
      <a class="navtrail" href="">Home</a> &gt; <a class="navtrail" href="">Admin Area</a> &gt; <a class="navtrail" href="">WebAccess Admin</a> &gt;
      <a class="navtrail" href="">Manage WebAccess</a> &gt; <a class="navtrail" href="">Role Administration</a>  &gt; Connect user to role
     </td>

    </tr>
   </table>

   <div class="pagebody">
    <table border="0" cellspacing="0" cellpadding="0" width="100%" summary="">
     <tr valign="top">
      <td class="pagebodystripemiddle" align="left">
       <h1 class="headline">Connect user to role </h1>
       <table class="admin_wvar" width="100%" summary="">
        <thead>
         <tr>
          <th class="adminheaderleft" colspan="2">step 1 - select a role</th>
         </tr>
        </thead>
        <tbody>
         <tr>
          <td style="vertical-align: top; margin-top: 5px; width: 75%;">
           <form action="" method="POST">
            <span class="adminlabel">1. select role</span>
            <select name="id_role" class="admin_w200">
             <option value="0">*** select role ***</option>
             <option value="2">photoadmin</option>
             <option value="9">submitter</option>
             <option value="1">superadmin</option>
             <option value="4">systemlibrarian</option>
             <option value="3">webaccessadmin</option>
            </select>
            <input class="adminbutton" type="submit" value="select role">
           </form>
          </td>
          <td style="vertical-align: top; margin-top: 5px; width: 25%;">
           <dl>
            <dt><a href="">Create new role</a></dt>
            <dd>go here to add a new role.</dd>
           </dl>
          </td>
         </tr>
        </tbody>
       </table>
      </td>
      <td class="pagebodystriperight" width="120" align="right" valign="top">
      </td>
     </tr>
    </table>
   </div>

</div>

<pre>

- step 2 - search for users

  As you can see, the subtitle of the page has now changed. The subtitle always tells you
  which step you are on and what your current task is.

  There can be possibly thousands of users using your online library, therefore it is important
  to make it easier to identify the user you are looking for. Give part of, or the entire search
  string and all users with partly matching e-mails will be listed on the next step.

  You can also see that the right hand menu has changed. This area is always updated with links
  to related admin areas.

</pre>

<div class="snapshot">

   <table border="0" cellspacing="0" cellpadding="0" class="navtrailbox" width="100%" summary="">
    <tr>
     <td class="navtrailboxbody">
      <a class="navtrail" href="">Home</a> &gt; <a class="navtrail" href="">Admin Area</a> &gt; <a class="navtrail" href="">WebAccess Admin</a> &gt;
      <a class="navtrail" href="">Manage WebAccess</a> &gt; <a class="navtrail" href="">Role Administration</a>  &gt; Connect user to role
     </td>

    </tr>
   </table>

   <div class="pagebody">
    <table border="0" cellspacing="0" cellpadding="0" width="100%" summary="">
     <tr valign="top">
      <td class="pagebodystripemiddle" align="left">
       <h1 class="headline">Connect user to role </h1>
       <table class="admin_wvar" width="100%" summary="">
        <thead>
         <tr>
          <th class="adminheaderleft" colspan="2">step 2 - search for users</th>
         </tr>
        </thead>
        <tbody>
         <tr>
          <td style="vertical-align: top; margin-top: 5px; width: 75%;">
           <form action="" method="POST">
            <span class="adminlabel">1. select role</span>
            <select name="id_role" class="admin_w200">
             <option value="0">*** select role ***</option>
             <option value="2">photoadmin</option>
             <option value="9">submitter</option>
             <option value="1" selected="selected">superadmin</option>
             <option value="4">systemlibrarian</option>
             <option value="3">webaccessadmin</option>
            </select>
            <input class="adminbutton" type="submit" value="select role">
           </form>
           <form action="" method="POST">
            <table summary="">
             <tr>
              <td>
               <span class="adminlabel">2. search pattern </span>
               <input class="admin_wvar" type="text" name="email_user_pattern" value="">
               <input type="hidden" name="id_role" value="1">
              </td>
              <td style="vertical-align: bottom">
               <input class="adminbutton" type="submit" value="search for users">
              </td>
             </tr>
            </table>
           </form>
          </td>
          <td style="vertical-align: top; margin-top: 5px; width: 25%;">
           <dl>
            <dt><a href="">Create new role</a></dt>
            <dd>go here to add a new role.</dd>
           </dl>
           <dl>
            <dt><a href="">Remove users</a></dt>
            <dd>remove users from role superadmin.</dd>
            <dt><a href="">Connected users</a></dt>
            <dd>show all users connected to role superadmin.</dd>
           </dl>
           <dl>
            <dt><a href="">Add authorization</a></dt>
            <dd>start adding new authorizations to role superadmin.</dd>
           </dl>
          </td>
         </tr>
        </tbody>
       </table>
      </td>
      <td class="pagebodystriperight" width="120" align="right" valign="top">
      </td>
     </tr>
    </table>
   </div>

</div>

<pre>

- step 3 - select a user.

  The select box contains all users with partly matching e-mail addresses. Select the one
  you want to connect to the role and continue.

  Notice the navigation trail that tells you were on the Administrator pages you are currently
  working.

</pre>

<div class="snapshot">

   <table border="0" cellspacing="0" cellpadding="0" class="navtrailbox" width="100%" summary="">
    <tr>
     <td class="navtrailboxbody">
      <a class="navtrail" href="">Home</a> &gt; <a class="navtrail" href="">Admin Area</a> &gt; <a class="navtrail" href="">WebAccess Admin</a> &gt;
      <a class="navtrail" href="">Manage WebAccess</a> &gt; <a class="navtrail" href="">Role Administration</a>  &gt; Connect user to role
     </td>

    </tr>
   </table>

   <div class="pagebody">
    <table border="0" cellspacing="0" cellpadding="0" width="100%" summary="">
     <tr valign="top">
      <td class="pagebodystripemiddle" align="left">
       <h1 class="headline">Connect user to role </h1>
       <table class="admin_wvar" width="100%" summary="">
        <thead>
         <tr>
          <th class="adminheaderleft" colspan="2">step 3 - select a user</th>
         </tr>
        </thead>
        <tbody>
         <tr>
          <td style="vertical-align: top; margin-top: 5px; width: 75%;">
           <form action="" method="POST">
            <span class="adminlabel">1. select role</span>
            <select name="id_role" class="admin_w200">
             <option value="0">*** select role ***</option>
             <option value="2">photoadmin</option>
             <option value="9">submitter</option>
             <option value="1" selected="selected">superadmin</option>
             <option value="4">systemlibrarian</option>
             <option value="3">webaccessadmin</option>
            </select>
            <input class="adminbutton" type="submit" value="select role">
           </form>

           <form action="" method="POST">
            <table summary="">
             <tr>
              <td>
               <span class="adminlabel">2. search pattern </span>
               <input class="admin_wvar" type="text" name="email_user_pattern" value="k">
               <input type="hidden" name="id_role" value="1">
              </td>
              <td style="vertical-align: bottom">
               <input class="adminbutton" type="submit" value="search for users">
              </td>
             </tr>
            </table>
           </form>

           <form action="" method="POST">
            <span class="adminlabel">3. select user</span>
            <select name="id_user" class="admin_w200">
             <option value="0">*** select user ***</option>
             <option value="136">franck.black@cern.ch</option>
             <option value="134">kurt.cobain@cern.ch</option>
             <option value="100" selected="selected">mikael.vik@cern.ch</option>
             <option value="-6">tibor.simko@cern.ch (connected)</option>
            </select>
            <input type="hidden" name="id_role" value="1">
            <input type="hidden" name="email_user_pattern" value="k">
            <input class="adminbutton" type="submit" value="add this user">
           </form>
          </td>
          <td style="vertical-align: top; margin-top: 5px; width: 25%;">
           <dl>
            <dt><a href="">Create new role</a></dt>
            <dd>go here to add a new role.</dd>
           </dl>
           <dl>
            <dt><a href="">Remove users</a></dt>
            <dd>remove users from role superadmin.</dd>
            <dt><a href="">Connected users</a></dt>
            <dd>show all users connected to role superadmin.</dd>
           </dl>
           <dl>
            <dt><a href="">Add authorization</a></dt>
            <dd>start adding new authorizations to role superadmin.</dd>
           </dl>
          </td>
         </tr>
        </tbody>
       </table>
      </td>
      <td class="pagebodystriperight" width="120" align="right" valign="top">
      </td>
     </tr>
    </table>
   </div>

</div>

<pre>

- step 4 - confirm to add user

  All WebAccess Administrator web pages display the action you are about to peform, this
  means explaining what kind of addition, change or update will be done to your access control
  data.

  If you are happy with your decision, simply confirm it.

</pre>

<div class="snapshot">

   <table border="0" cellspacing="0" cellpadding="0" class="navtrailbox" width="100%" summary="">
    <tr>
     <td class="navtrailboxbody">
      <a class="navtrail" href="">Home</a> &gt; <a class="navtrail" href="">Admin Area</a> &gt; <a class="navtrail" href="">WebAccess Admin</a> &gt;
      <a class="navtrail" href="">Manage WebAccess</a> &gt; <a class="navtrail" href="">Role Administration</a>  &gt; Connect user to role
     </td>

    </tr>
   </table>

   <div class="pagebody">
    <table border="0" cellspacing="0" cellpadding="0" width="100%" summary="">
     <tr valign="top">
      <td class="pagebodystripemiddle" align="left">
       <h1 class="headline">Connect user to role </h1>
       <table class="admin_wvar" width="100%" summary="">
        <thead>
         <tr>
          <th class="adminheaderleft" colspan="2">step 4 - confirm to add user</th>
         </tr>
        </thead>
        <tbody>
         <tr>
          <td style="vertical-align: top; margin-top: 5px; width: 75%;">
           <form action="" method="POST">
            <span class="adminlabel">1. select role</span>
            <select name="id_role" class="admin_w200">
             <option value="0">*** select role ***</option>
             <option value="2">photoadmin</option>
             <option value="9">submitter</option>
             <option value="1" selected="selected">superadmin</option>
             <option value="4">systemlibrarian</option>
             <option value="3">webaccessadmin</option>
            </select>
            <input class="adminbutton" type="submit" value="select role">
           </form>

           <form action="" method="POST">
            <table summary="">
             <tr>
              <td>
               <span class="adminlabel">2. search pattern </span>
               <input class="admin_wvar" type="text" name="email_user_pattern" value="k">
               <input type="hidden" name="id_role" value="1">
              </td>
              <td style="vertical-align: bottom">
               <input class="adminbutton" type="submit" value="search for users">
              </td>
             </tr>
            </table>
           </form>

           <form action="" method="POST">
            <span class="adminlabel">3. select user</span>
            <select name="id_user" class="admin_w200">
             <option value="0">*** select user ***</option>
             <option value="136">franck.black@cern.ch</option>
             <option value="134">kurt.cobain@cern.ch</option>
             <option value="100" selected="selected">mikael.vik@cern.ch</option>
             <option value="-6">tibor.simko@cern.ch (connected)</option>
            </select>
            <input type="hidden" name="id_role" value="1">
            <input type="hidden" name="email_user_pattern" value="k">
            <input class="adminbutton" type="submit" value="add this user">
           </form>

           <form action="" method="POST">
            <table summary="">
             <tr>
              <td>add user <strong>mikael.vik@cern.ch</strong> to role <strong>superadmin</strong>?
               <input type="hidden" name="confirm" value="1">
               <input type="hidden" name="id_user" value="100">
               <input type="hidden" name="id_role" value="1">
               <input type="hidden" name="email_user_pattern" value="k">
              </td>
              <td style="vertical-align: bottom">
               <input class="adminbutton" type="submit" value="confirm" />
              </td>
             </tr>
            </table>
           </form>
          </td>
          <td style="vertical-align: top; margin-top: 5px; width: 25%;">
           <dl>
            <dt><a href="">Create new role</a></dt>
            <dd>go here to add a new role.</dd>
           </dl>
           <dl>
            <dt><a href="">Remove users</a></dt>
            <dd>remove users from role superadmin.</dd>
            <dt><a href="">Connected users</a></dt>
            <dd>show all users connected to role superadmin.</dd>
           </dl>
           <dl>
            <dt><a href="">Add authorization</a></dt>
            <dd>start adding new authorizations to role superadmin.</dd>
           </dl>
          </td>
         </tr>
        </tbody>
       </table>
      </td>
      <td class="pagebodystriperight" width="120" align="right" valign="top">
      </td>
     </tr>
    </table>
   </div>

</div>

<pre>

- step 5 - confirm user added.

  The user has now been added to this role. You can easily continue adding more users to this
  role be restarting from step 2 or 3. You can also go directly to another area and keep working
  on the same role.

</pre>

<div class="snapshot">

   <table border="0" cellspacing="0" cellpadding="0" class="navtrailbox" width="100%" summary="">
    <tr>
     <td class="navtrailboxbody">
      <a class="navtrail" href="">Home</a> &gt; <a class="navtrail" href="">Admin Area</a> &gt; <a class="navtrail" href="">WebAccess Admin</a> &gt;
      <a class="navtrail" href="">Manage WebAccess</a> &gt; <a class="navtrail" href="">Role Administration</a>  &gt; Connect user to role
     </td>

    </tr>
   </table>

   <div class="pagebody">
    <table border="0" cellspacing="0" cellpadding="0" width="100%" summary="">
     <tr valign="top">
      <td class="pagebodystripemiddle" align="left">
       <h1 class="headline">Connect user to role </h1>
       <table class="admin_wvar" width="100%" summary="">
        <thead>
         <tr>
          <th class="adminheaderleft" colspan="2">step 5 - confirm user added</th>
         </tr>
        </thead>
        <tbody>
         <tr>
          <td style="vertical-align: top; margin-top: 5px; width: 75%;">
           <form action="" method="POST">
            <span class="adminlabel">1. select role</span>
            <select name="id_role" class="admin_w200">
             <option value="0">*** select role ***</option>
             <option value="2">photoadmin</option>
             <option value="9">submitter</option>
             <option value="1" selected="selected">superadmin</option>
             <option value="4">systemlibrarian</option>
             <option value="3">webaccessadmin</option>
            </select>
            <input class="adminbutton" type="submit" value="select role">
           </form>

           <form action="" method="POST">
            <table summary="">
             <tr>
              <td>
               <span class="adminlabel">2. search pattern </span>
               <input class="admin_wvar" type="text" name="email_user_pattern" value="k">
               <input type="hidden" name="id_role" value="1">
              </td>
              <td style="vertical-align: bottom">
               <input class="adminbutton" type="submit" value="search for users">
              </td>
             </tr>
            </table>
           </form>

           <form action="" method="POST">
            <span class="adminlabel">3. select user</span>
            <select name="id_user" class="admin_w200">
             <option value="0">*** select user ***</option>
             <option value="136">franck.black@cern.ch</option>
             <option value="134">kurt.cobain@cern.ch</option>
             <option value="100" selected="selected">mikael.vik@cern.ch</option>
             <option value="-6">tibor.simko@cern.ch (connected)</option>
            </select>
            <input type="hidden" name="id_role" value="1">
            <input type="hidden" name="email_user_pattern" value="k">
            <input class="adminbutton" type="submit" value="add this user">
           </form>

           <form action="" method="POST">
            <table summary="">
             <tr>
              <td>add user <strong>mikael.vik@cern.ch</strong> to role <strong>superadmin</strong>?
               <input type="hidden" name="confirm" value="1">
               <input type="hidden" name="id_user" value="100">
               <input type="hidden" name="id_role" value="1">
               <input type="hidden" name="email_user_pattern" value="k">
              </td>
              <td style="vertical-align: bottom">
               <input class="adminbutton" type="submit" value="confirm" />
              </td>
             </tr>
            </table>
           </form>

           <p>confirm: user <strong>mikael.vik@cern.ch</strong> added to role <strong>superadmin</strong>.</p>

          </td>
          <td style="vertical-align: top; margin-top: 5px; width: 25%;">
           <dl>
            <dt><a href="">Create new role</a></dt>
            <dd>go here to add a new role.</dd>
           </dl>
           <dl>
            <dt><a href="">Remove users</a></dt>
            <dd>remove users from role superadmin.</dd>
            <dt><a href="">Connected users</a></dt>
            <dd>show all users connected to role superadmin.</dd>
           </dl>
           <dl>
            <dt><a href="">Add authorization</a></dt>
            <dd>start adding new authorizations to role superadmin.</dd>
           </dl>
          </td>
         </tr>
        </tbody>
       </table>
      </td>
      <td class="pagebodystriperight" width="120" align="right" valign="top">
      </td>
     </tr>
    </table>
   </div>

</div>

<pre>

- we are done

  This example is very similar to all the other pages where you administrate WebAccess. The pages
  are an easy gateway to maintaing access control rights and share a lot of features.
  - divided into steps
  - restart from any wanted step (not undo)
  - changes must be confirmed
  - link to other relevant areas
  - prevent unwanted input

  As an administrator with access to these pages you are free to manage the rights any way you want.
</pre>

<h2><a name="4">IV. Managing accounts and access policy</a></h2>
<pre>
  Here you can administrate the accounts and the access policy for your CDS Invenio installation.

  - Access policy:

    To change the access policy, the general config file (or
    access_control_config.py) must be edited manually in a text
    editor. The site can there be defined as opened or closed, you can
    edit the access policy level for guest accounts, registered
    accounts and decide when to warn the owner of the account when
    something happens with it, either when it is created, deleted or
    approved.  The Apache server must be restarted after modifying
    these settings.

    The two levels for guest account, are:
       0 - Allow guest accounts
       1 - Do not allow guest accounts
    The five levels for normal accounts, are:
       0 - Allow user to create account, automatically activate new accounts
       1 - Allow user to create account, administrator must activate account
       2 - Only administrators can create account. User cannot edit the email address.
       3 - Users cannot register or update account information (email/password)
       4 - User cannot change default login method
    You can configure CDS Invenio to send an email:
       1. To an admin email-address when an account is created
       2. To the owner of an account when it is created
       3. To the owner of an account when it is activated
       4. To the owner of an account when it is deleted

    Define how open the site is:
      0 = normal operation of the site
      1 = read-only site, all write operations temporarily closed
      2 = site fully closed
      3 = database connections disabled
      CFG_ACCESS_CONTROL_LEVEL_SITE = 0
    Access policy for guests:
      0 = Allow guests to search,
      1 = Guests cannot search (all users must login)
      CFG_ACCESS_CONTROL_LEVEL_GUESTS = 0
    Access policy for accounts:
      0 = Users can register, automatically acticate accounts
      1 = Users can register, but admin must activate the accounts
      2 = Users cannot register or change email address, only admin can register accounts.
      3 = Users cannot register or update email address or password, only admin can register accounts.
      4 = Same as 3, but user cannot change login method.
      CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS = 0

    Limit email addresses available to use when register a new account (example: cern.ch):
      CFG_ACCESS_CONTROL_LIMIT_REGISTRATION_TO_DOMAIN = ""

    Send an email when a new account is created by an user:
      CFG_ACCESS_CONTROL_NOTIFY_ADMIN_ABOUT_NEW_ACCOUNTS = 0

    Send an email to the user notifying when the account is created:
      CFG_ACCESS_CONTROL_NOTIFY_USER_ABOUT_NEW_ACCOUNT = 0

    Send an email to the user notifying when the account is activated:
      CFG_ACCESS_CONTROL_NOTIFY_USER_ABOUT_ACTIVATION = 0

    Send an email to the user notifying when the account is deleted/rejected:
      CFG_ACCESS_CONTROL_NOTIFY_USER_ABOUT_DELETION = 0

  - Account overview:
    Here you find an overview of the number of guest accounts, registered accounts and accounts
    awaiting activation, with a link to the activation page.

  - Create account:
    For creating new accounts, the email address must be unique. If configured to do so, an email
    will be sent to the given address when an account is created.

  - Edit accounts:
    For activating or rejecting accounts in addition to modifying them. An activated account can be
    inactivated for a short period of time, but this will not warn the account owner. To find accounts
    enter a part of the email address of the account and then search. This may take some time. If there
    are more than the selected number of accounts per page, you can use the next/prev links to switch
    pages. The accounts to search in can also be limited to only activated or not activated accounts.

  - Edit account:
    When editing one account, you can change the email address, password, delete the account, or modify
    the baskets or alerts belonging to one account. Which login method should be the default for this
    account can also be selected. To modify baskets or alerts, you need to login as the user, and
    modify the desired data as a normal user. Remember to log out as the user when you are finished
    editing.

</pre>

<h2><a name="5">V. Managing login methods</a></h2>
<pre>
   CDS Invenio supports using external login systems to authenticate users.

   When a user wants to login, the username and password given by the user is checked against the selected
   system, if the user is authenticated by the external system, a valid email-address is returned to
   CDS Invenio and used to recognize the user within CDS Invenio.

   If a new user is trying to login without having an account, using an external login system, an account
   is automatically created in CDS Invenio to recognize and store the users settings. The password for the
   local account is randomly generated.

   If you want the user to be unable to change login method and account username / password, forcing use
   of certain external systems, set <strong>CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS</strong> to <em>4</em> as mentioned in the last paragraph.

   If a user is changing login method from an <em>external</em> one to the <em>internal</em>, he also need to either change the
   password before logging out, or set the password via the lost password email service.

   If you are using <strong>CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS</strong> with a value greater than <em>1</em> note
   that, even if the first login of a user through an external authentication technically means registering
   the user into the system, this is not the semantic expected behaviour by the user. The user is already
   <em>registered</em> at an authority that we trust, so there's no need to prevent the user from being imported
   into the system. That's why for external authentication <strong>CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS</strong> is not
   considered apart from what said above.

   If a external login system is used, you may want to protect the users username / password using <strong>HTTPS</strong>.

   To add new system, two changes must be made (for the time being):
   - The name of the method, if it is default or not, and the classname must be added to the variable
     <strong>CFG_EXTERNAL_AUTHENTICATION</strong> in <em>access_control_config.py</em>. Atleast one method must be marked as the
     default one. The internal login method should be given with None as classname.

     Example:
      CFG_EXTERNAL_AUTHENTICATION = {"%s (internal)" % CFG_SITE_NAME: (None, True), "CERN NICE (external)":
                                                        (AuthCernWrapper(), False)}

   - A class must be created derived from the class external_authentication inside file
     <em>external_authentication.py</em>. This class must include at least the
     function <strong>auth_user</strong>. This function returns a valid email-address in <em>CDS Invenio</em> if the user
     is authenticated, not necessarily the same entered by the user as username. If the user
     is not authenticated, return <em>None</em>.
     The class could also provide five more methods: <strong>fetch_user_preferences</strong>, <strong>user_exists</strong>,
     <strong>fetch_user_groups_membership</strong> and <strong>fetch_all_users_groups_membership</strong>.
     The first should take an email and eventually a password and should return a dictionary of keys
     and value representing external preferences, infos or settings. If, for some reasons, you like
     to force some kind of hiding for some particular field you should export the related key
     prefixed by <em>"HIDDEN_"</em>. Those fields won't be displayed in tables and pages regarding external
     settings.
     The second method should check through the external system if a particular email exists. If you
     provide such a method then a user will be able to switch from and to this authorization method.
     The third method should take an email and (if necessary) a password
     and should return a dictionary of external_groups_names toghether with their description, for which
     the user has a membership. Those groups will be merged into the groups system.
     The user will be a member of those groups and will be able to use them in any place
     where groups are useful, but won't be able to unsubscribe or to administrate them.
     The fourth method should just return a dictionary of external groups as keys and tuples containing
     a group description and a list of email of users belonging to each groups. Those memberships
     will be merged into the database in the way done by the previous method, but could
     provide batch synchronization of groups.
     The fifth method should just return the nickname as is known by the external authentication
     system, given the usual email/username and the password.
     Note: if your system has more than one external login methods then incoherence in the groups
     memberships could happen when a user switch his login method. This will be fixed some times in the
     future.
     If you add as an attribute of your class the <strong>enforce_external_nicknames</strong> and set it to <em>True</em>, this will enforce
     the system to import external nicknames whenever the user login with the external login method for the
     first time. Since a nickname is not changable this will stay fixed forever. If this nickname is
     already registered in the system (suppose that is linked with a local account) then it will not be
     imported. If this variable doesn't exist or is set to <em>False</em> then no nickname will be
     imported and the user will be free to choose a nickname in the future (and then this will again
     stay forever).
     Note: every method will receive as last parameter the <em>mod_python request object</em>, that could
     be used for particular purposes.


     Example template:
     from invenio.external_authentication import ExternalAuth, InvenioWebAccessExternalAuthError

     class ExternalAuthFoo(ExternalAuth):
         """External authentication template example."""

         def __init__ (self):
             """Initialize stuff here."""
             self.name = None
             self.enforce_external_nicknames = False
             pass

         def auth_user(self, username, password, req=None):
             """Authenticate user-supplied USERNAME and PASSWORD.
             Return None if authentication failed, or the email address of the
             person if the authentication was successful.  In order to do
             this you may perhaps have to keep a translation table between
             usernames and email addresses.
             Raise InvenioWebAccessExternalAuthError in case of external troubles.
             """
             raise NotImplementedError
             #return None

         def user_exists(self, email, req=None):
             """Checks against external_authentication for existance of email.
             @return True if the user exists, False otherwise
             """
             raise NotImplementedError

         def fetch_user_groups_membership(self, username, password=None, req=None):
             """Given a username, returns a dictionary of groups
             and their description to which the user is subscribed.
             Raise InvenioWebAccessExternalAuthError in case of troubles.
             """
             raise NotImplementedError
             #return {}

         def fetch_user_preferences(self, username, password=None, req=None):
             """Given a username and a password, returns a dictionary of keys and
             values, corresponding to external infos and settings.

             userprefs = {"telephone": "2392489",
             "address": "10th Downing Street"}
             """
             raise NotImplementedError
            #return {}

         def fetch_all_users_groups_membership(self, req=None):
             """Fetch all the groups with a description, and users who belong to
             each groups.
             @return {'mygroup': ('description', ['email1', 'email2', ...]), ...}
             """
             raise NotImplementedError

         def fetch_user_nickname(self, username, password, req=None):
             """Given a username and a password, returns the right nickname belonging
             to that user (username could be an email).
             """
             raise NotImplementedError
             #return Nickname
</pre>

<h2><a name="6">VI. FIREWALL-LIKE ROLE DEFINITIONS</a></h2>

    <strong>The FireRole language description</strong>

    <pre>
    In the WebAccess RBAC system, roles are built up from their names,
    description and definition.

    A definition is the way to <em>formally implicitly define</em> which users belong
    to which roles.

    A definition is expressed in a <em>firewall like rules language</em>. It's built up
    by rows which are matched from top to bottom, in order to decide if the
    current user (wethever he/she is logged in or not) may belong to a role.

    Any row has this syntax:

        <strong>ALLOW/DENY ANY/ALL</strong>

        or

        <strong>ALLOW/DENY [NOT] <em>field</em> {<em>one or more values</em>}</strong>

    The rows are parsed from top to bottom. If a row matches the user than the
    user belongs to the role if the rule is an ALLOW rule, otherwise, if the
    rule is a DENY one, the user doesn't belong to the role.

    A rule of the kind ALLOW|DENY ANY always matches, regardless of the user.

    Note, in place of ANY you can use the word ALL. The semantic is the same. The
    system support both to let the user comply with the English grammar.

    The second type of rule is interpreted as follows: given a dictionary
    of keys:values describing a user (we will cover this below), the rule
    considers the value associated with the key named in field, and checks
    if it corresponds to at least one of the values in the "one or more values" list.
    This is a list of comma separated strings, which can be literal
    (double-)quoted strings or regexps (marked by `/' ... `/' signs). If at
    least a value matches (literally or through the regexp language), the
    whole rule is considered to match.
    If the optional NOT keyword is specified than if at least a value of the
    rule matches the rule is skipped, otherwise if all the value of the rules
    don't match the whole rule matches.

    A <strong>DENY ALL</strong> rule is implicitly added at the end of every definition.

    Any field is valid, but only rules concerning fields which currently
    exist in the user describing dictionary are checked. All the rules
    with non existant fields are skipped.

    The user describing dictionary (user_info) is built at runtime with all the informations
    that can be gathered about the current user (and its session).
    Currently valid fields are: <em>uid, email, nickname, apache_user, remote_ip,
    remote_host, groups, apache_groups</em> and all the external settings provided
    by the external authentication systems (e.g. CERN SSO provides:
    external_authmethod, external_building, external_department, external_email,
    external_external, external_firstname, external_fullname, external_homdir,
    external_homeinstitute, external_lastname, external_login, external_mobilenumber,
    external_phonenumber).

    Among those fields there are some special cases, which are <em>remote_ip</em> and
    (<em>apache_</em>)<em>groups</em>. Rules can refer to remote_ip either using a literal
    expression for specifing list of single ips, or a usual regexp (or list
    of regexps), or, also, using the common network group/mask notation
    (e.g. <em>"127.0.0.0/24"</em>) as a literal string, which is a mix between literal
    expressions and regexps. (apache_)groups are related to group memberships.
    Since a user will probably belong to more than a group, then the rule
    matches if there's at least one group to which the user belong, that matches
    at least one of the expressions (NOT rules behave as you can imagine).

    The dictionary is built using the current user session. If the user is
    authenticated in some way (apache, locally, externally, SSO...) then more
    infos could be provided to the firerole system in order to decide if the
    user should belong to a role or not.

    The default fields that are always there are:
    <ul>
        <li><strong>uid</strong>: an integer representing the user id</li>
        <li><strong>nickname</strong>: the nickname of the user</li>
        <li><strong>email</strong>: the email of the user</li>
        <li><strong>group/groups</strong>: local or external group to which the user belong</li>
        <li><strong>guest</strong>: 1 if the user is a guest (not logged), 0 otherwise</li>
    </ul>
    plus all the external setting retrieved by an <a href="webaccess-admin-guide#5">external authentication system</a>.

    If the action to which the role defined is raised from the webinterface of
    CDS Invenio, then you will have those additional fields:
    <ul>
        <li><strong>remote_ip</strong>: the remote ip address of the user who is browsing</li>
        <li><strong>remote_host</strong>: the remote hostname of the user who is browsing</li>
        <li><strong>referer</strong>: the webpage from where the user is coming from</li>
        <li><strong>uri</strong>: the uri the user is visiting</li>
        <li><strong>agent</strong>: the agent string describing the user's browser</li>
        <li><strong>apache_user</strong>: the <a href="websearch-admin-guide#3.2">Apache user</a> provided by the authenticated user</li>
        <li><strong>apache_group/apache_groups</strong>: the Apache groups to which the apache user
            belong</li>
    </ul>

    Note that you can specify either (apache_)group or (apache_)groups (with or
    without the trailing s). They are semantically equal and are supported just
    to let people comply with the English grammar.

    Every rule is <em>case-insensitive</em> (apart values which must match literally
    and regexp values which don't explicitly specify case-insesitive matches).

    Every rule may contain <em>comments</em> preceded by the '<em>#</em>' character.
    Any comment is discarded.

    When you set a definition for a role, it is actually compiled and stored
    in a binary compressed form inside the database. If the syntax isn't correct
    this will be stated and the definition won't be set or updated.

    Example of role definition:
        allow not email /.*@gmail.com/,/.*@hotmail.com/
        deny group badguys
        allow remote_ip "127.0.0.0/24"
        deny all

    This definition would match all users whose emails don't end with @gmail.com and
    @hotmail.com, or who don't belong to the group badguys and have remote_ip
    in the 24bit mask network of 127.0.0.0. All the the other users don't belong
    to the role which is being defined.

    If you want to discover which keys are available on your system to build a FireRole
    rule, just login with your account in your installation and visit <a href="<CFG_SITE_SECURE_URL>/youraccount/edit?verbose=9">your account page</a>,
    by activating verbose=9 variable. Under the tile you will se the available keys and
    values that you can use to build a FireRole rule. All but fields prefixed with
    <strong>precached_</strong> are usuable.
   </pre>
